home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 4⁄20⁄90 / 0104-Re[2] OOPascal vs. C-Apr90 < prev    next >
Encoding:
Text File  |  1990-04-23  |  3.3 KB  |  77 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    5805826                         20-April-90        11:20PDT
  4.  
  5. From:   D4280                           IDS, Robert Pappas,PRT
  6.  
  7. To:     JL.TECH                         Jostens Learning, Eduard Schwan,VAR
  8.  
  9. cc:     ALGER                           Alger, Jeff,VCA
  10.         CPLUS.DEV$                      C++ Interest List--Developers
  11.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  12.         MACAPP.TECH$                    MacApp Technical
  13.  
  14. Sub:    RE:RE: OOPascal vs. C++
  15.  
  16.  
  17. Jeff & Paul:
  18.  
  19. We have embarked on a large C++/MacApp project.
  20.  
  21. We chose C++ because we believe that it will be supported across more platforms
  22. than OPascal. Since we are a large corporation, we have to keep platforms in
  23. mind. And if the day that we need to switch to a different platform (heaven
  24. forbid), C++ will probably be the most supported language.
  25. The DOS world will soon have some large C++ object libraries.
  26.  
  27. If I could have one more feature of C++, I would ask for nested procedures and
  28. the variable scoping that O Pascal has. It is not a major road-block and you
  29. get used to it, you don't loose any features.
  30.  
  31. Our project takes 50 minutes to do a complete build. And it is only 33% done.
  32. We expect this value to increase to 150 minutes.
  33. Using a feature called load/dump with C++, the compile time is reduced by a
  34. factor of 2-3.
  35. When you ask C++ to dump something, it parses through the header files you give
  36. it, checking syntax and basically creating a large table of symbol mapping that
  37. is dumped into a file.
  38. So when it comes time to compile, the compiler just loads this large dump file
  39. quickly. If you follow Apples convention of
  40.                                             #ifndef __headerfile__
  41.                                             #include "headerfile.h"
  42.                                             #endif
  43. the symbol __headerfile__ will already be defined in the dump file so the
  44. #include will not be executed, greatly speeding up your compile times.
  45.  
  46. A very large percentage of compile times is just parsing the MacApp headers and
  47. your header files.
  48.  
  49. Our 50 minutes becomes 20 minutes.
  50.  
  51. We are also trying to get Jasiks IBS stuff to work, which doesn't help compile
  52. times, but helps linking times and debugging. You can do source level debugging
  53. like SADE, and when you find a mistake you can jump over to MPW and make your
  54. change, compile, and then jump back to the debugger and continue stepping
  55. through your source code! But, it does not work well yet.
  56.  
  57. Another problem is the MacApp debugger does not display the fields of the
  58. object correctly. The Inspector can. So any fields method you write, you cannot
  59. see the values from the MacApp debugger. The problem is in the way C++ handles
  60. strings in a record. O Pascal can account for them, C++ can't.
  61.  
  62. Also, load/dump does not work with symbols generation turned on for SADE. This
  63. is supposed to be fixed in the final release of C++ comming out in 2-3 weeks...
  64. (Right?)
  65.  
  66. I also prefer C++ because I like to keep track of low level things that O
  67. Pascal does automatically for you. (I'm an old 68000 programmer from way back,
  68. counting parameters on the stack and weird stuff like that)
  69.  
  70. If you use MacApp, you will never be far away from O Pascal anyway.
  71.  
  72.  
  73. Bob Pappas
  74. IDS Financial Services
  75.  
  76.  
  77.